dpci: move from an hvm_irq_dpci (and struct domain) to an hvm_dirq_dpci model

dpci: move from an hvm_irq_dpci (and struct domain) to an hvm_dirq_dpci model

When an interrupt for an PCI (or PCIe) passthrough device is to be sent
to a guest, we find the appropiate 'hvm_dirq_dpci' structure for the
interrupt (PIRQ), set a bit (masked), and schedule an tasklet.

Then the 'hvm_dirq_assist' tasklet gets called with the 'struct domain'
from where it iterates over the the radix-tree of 'hvm_dirq_dpci' (from
zero to the number of PIRQs allocated) which are masked to the guest
and calls each 'hvm_pirq_assist'. If the PIRQ has a bit set (masked) it
figures out how to inject the PIRQ to the guest.

This is inefficient and not fair as:
 - We iterate starting at PIRQ 0 and up every time. That means the PCIe
   devices that have lower PIRQs get to be called first.
 - If we have many PCIe devices passed in with many PIRQs and if most
   of the time only the highest numbered PIRQ get an interrupt (as the
   initial ones are for control) we end up iterating over many PIRQs.

But we could do beter - the 'hvm_dirq_dpci' has the field for
'struct domain', which we can use instead of having to pass in the
'struct domain'.

As such this patch moves the tasklet to the 'struct hvm_dirq_dpci' and
sets the 'dom' field to the domain. We also double-check that the
'->dom' is not reset before using it.

We have to be careful with this as that means we MUST have 'dom' set
before pirq_guest_bind() is called. As such we add the
'pirq_dpci->dom = d;' to cover for such cases.

The mechanism to tear it down is more complex as there are two ways it
can be executed:

 a) pci_clean_dpci_irq. This gets called when the guest is being
    destroyed. We end up calling 'tasklet_kill'.

    The scenarios in which the 'struct pirq' (and subsequently the
    'hvm_pirq_dpci') gets destroyed is when:

    - guest did not use the pirq at all after setup.
    - guest did use pirq, but decided to mask and left it in that
      state.
    - guest did use pirq, but crashed.

    In all of those scenarios we end up calling 'tasklet_kill' which
    will spin on the tasklet if it is running.

 b) pt_irq_destroy_bind (guest disables the MSI). We double-check that
    the softirq has run by piggy-backing on the existing
    'pirq_cleanup_check' mechanism which calls 'pt_pirq_cleanup_check'.
    We add the extra call to 'pt_pirq_softirq_active' in
    'pt_pirq_cleanup_check'.

    NOTE: Guests that use event channels unbind first the event channel
    from PIRQs, so the 'pt_pirq_cleanup_check' won't be called as event
    is set to zero. In that case we either clean it up via the a)
    mechanism. It is OK to re-use the tasklet when 'pt_irq_create_bind'
    is called afterwards.

    There is an extra scenario regardless of event being set or not:
    the guest did 'pt_irq_destroy_bind' while an interrupt was
    triggered and tasklet was scheduled (but had not been run). It is
    OK to still run the tasklet as hvm_dirq_assist won't do anything
    (as the flags are set to zero). As such we can exit out of
    hvm_dirq_assist without doing anything.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>